\chapter{Opis problemu}

W pierwszej części zostanie przedstawiona tematyka pracy oraz aktualnie dostępne rozwiązania
problemów z nią związanych.

\section{Wybór tematyki}

W dzisiejszych czasach moc obliczeniowa średniej klasy laptopa jest kilka tysięcy razy większa niż
komputerów z początku lat 60-tych ubiegłego wieku. W ciągu 50 lat komputery z wojskowych i naukowych
ośrodków badawczych przeniosły się do naszych domów w różnych formach: komputerów stacjonarnych,
laptopów, ostatnio nawet telefonów. Prawo Moore'a przez ostatnie 50 lat było nieomylne. Jednak
podwajanie się liczby tranzystorów co rok powoli traci na znaczeniu. Dzisiaj myśli się bardziej
"równolegle". Buduje się komputery, które posiadają liczbę procesorów mierzoną w tysiącach. Dzięki
temu umożliwia się wykonywanie obliczeń szybciej, po przez ich podział pomiędzy większą liczbę
jednostek wykonywalnych.

Ośrodki badawcze, których cele są bardzo zróżnicowane, od szukania nowych leków po analizy
danych z Wielkiego Zderzacza Hadronów (LHC), potrzebują maszyn o ogromnych mocach obliczeniowych.
Wiele z nich łączy siły, a co za tym idzie i moc obliczeniową swoich komputerów, tworząc tzw.
\emph{grid}. Pozwala to na współdzielenie cennego zasobu, jakim niewątpliwie w dzisiejszych czasach
jest czas pracy superkomputerów. Tworzone są w ramach takiej współpracy systemy komputerowe zwane
systemami gridowymi. Unicore jest jednym z systemów informatycznych umożliwiających budowę systemu gridowego.

Na systemach klasy Unicore użytkownicy mogą uruchamiać aplikacje, które dzięki odpowiedniemu
zrównolegleniu mogą wykonywać się szybciej i przyjmować więcej danych do obliczeń. Wiele z tych
aplikacji niestety nie posiada interfejsu graficznego, który ludziom nie posiadającym wiedzy
programistyczniej ułatwiłby zarówno wprowadzanie danych jak i odbieranie wyników. Dlatego
zatrudniani do pracy są programiści, którzy projektują graficzną reprezentację aplikacji. Niestety
wymaga to czasu i środków w postaci wykwalifikowanej kadry informatycznej.

Aplikacje używane przez naukowców często mają postać programów wsadowych, które uruchamia się z
linii poleceń systemu operacyjnego. Aplikacja taka najczęściej posiada możliwość ustawienia kilku
parametrów oraz przekierowania strumieni wejścia i wyjścia, w celu dostarczenia danych i
wyprowadzenia wyników swojego działania. Wywołanie może wyglądać w następujący sposób:

\begin{minted}{bash}
$ prog.exe -p1 -p2 -p3 < plik_wejsciowy.txt > plik_wyjsciowy.txt
\end{minted}

Praca z taką aplikacją pociąga za sobą kilka niedogodności. Czasami użytkownik chciałby wprowadzić
kilka plików wejściowych lub podzielić wyniki na kilka części. Każdy program ma swój format
wprowadzanych danych, który najczęściej jest rozumiany tylko przez niego samego. Wiele możliwości
ustawiania parametrów może łatwo doprowadzić do wybrania niewłaściwego. Niekiedy programy wymagają
do uruchomienia dodatkowych narzędzi, np.: \texttt{mpirun} dla komunikacji równoległej MPI lub
parsera języka skryptowego.

Chęć uproszczenia pracy z programami naukowymi, a co za tym idzie przyśpieszenia pracy wielu naukowców
była jednym z kryteriów wyboru tematu.

Drugim, równie znaczącym powodem, była potrzeba poznania coraz to szybciej rozwijających się technologii
internetowych. Duża część firm rezygnuje, z kiedyś popularnych, aplikacji typu desktop na rzecz
rozbudowanych stron internetowych, które zyskały już dawno miano aplikacji internetowych. Dzięki
takiemu podejściu, praktycznie od razu, aplikacja taka zyskuje olbrzymi atut w postaci ogólnej
dostępności, wieloplatformowości oraz rozproszoności.

Kosztem uruchomienia aplikacji internetowej jest posiadanie serwera, którego zadaniem jest
udostępnienie jej (ang. hosting) oraz przeglądarka WWW dla każdego z użytkowników systemu.
Dzisiejsze komputery, nawet te najtańsze, bez problemu mogą sprostać tym wymaganiom.

Problem polega jednak na tym, że mimo obszernej ilości narzędzi do tworzenia takich aplikacji,
dziedzina ta jest jeszcze dosyć młoda. Dlatego warto szukać nowych rozwiązań, jeśli chodzi o
efektywne projektowanie i implementowanie tego typu systemów.

\section{Dostępne rozwiązania}

Tworzenie interfejsów dla aplikacji gridowych nie jest zagadnieniem nowym. Od dłuższego czasu
powstają narzędzia, które próbują to zadanie ułatwić. Oto kilka z nich, które są warte bliższej
uwagi.

\subsection{GridBean}

Pojęcie \emph{GridBeanu} pojawia się w związku koncepcją środowiska programowania gridu (ang. Grid
Programming Environment, w skrócie GPE). Jest do zbiór interfejsów i klas bazowych w języku Java
umożliwiających tworzenie interfejsu użytkownika dla aplikacji uruchamianej w środowsku gridowym
\cite{grid-bean}. Zadaniem \emph{GridBeanu} jest:

\begin{itemize}

\item Generowanie opisu zadania w języku JSDL, na potrzeby uruchamiania aplikacji w systemie
gridowym;

\item Dostarczenie interfejsu użytkownika na potrzeby wprowadzania danych wejściowych;

\item Dostarczenie interfejsu użytkownika na potrzeby wyświetlania danych wyjściowych;

\item Dostarczenie interfejsu użytkownika na potrzeby interakcji z systemem gridowym.

\end{itemize}

Typowy \emph{GridBean} dzieli się na dwie główne części:

\begin{itemize}

\item Pojedynczy moduł generujący opis zadania;

\item Jeden lub więcej modułów reprezentujących interfejs użytkownika.

\end{itemize}

Gotowy \emph{GridBean} jest wysyłany do \emph{serwisu GridBean} (ang. \emph{GridBean Service}).
Aplikacje klienckie tworzone zgodnie z założeniami GPE potrafią łączyć się z takim serwisem i
pobierać dostępne w nich \emph{GridBeany}. Przykładem takiej aplikacji jest Unicore Rich Client.

Zdecydowaną wadą specyfikacji \emph{GridBean} jest fakt, że wyprodukowaniem interfejsu musi się
zająć programista znający dość dobrze język Java. Dodatkowo ilość kodu, która musi zostać
wyprodukowana nie jest najmniejszą z możliwych.

Warto także nadmienić, że podczas projektowania specyfikacji \emph{GridBean}, nie planowano
możliwości jego osadzania w środowisku internetowym. Podejmowane ku temu próby nie przyniosły
oczekiwanych rezultatów.

\subsection{WebGridBean}

Próbą zastąpienia koncepcji \emph{GridBeanu} była praca nad specyfikacją \emph{WebGridBean} i
internetowym klientem systemu Unicore \cite{web-grid-bean}. Świeżość tego podejścia polegała na tym,
że interfejs użytkownika był opisywany na zasadzie kodu JSP (Java Server Pages), który jest
dialektem języka XML. Aplikacja WebClient potrafiła przyjąć taki opis zadania i w
połączeniu z przetworzeniem go do postaci \emph{GridBeanu}, przesłać do instancji systemu Unicore i
uruchomić.

Przyjęcie takiej formy zapisu, zmniejszyła ilość kodu, który trzeba było napisać. Jednak dla
zaprojektowania bardziej wyrafinowanego interfejsu potrzeba było znów programisty, który
dysponowałby wiedzą na temat pisania skryptów JSP. Podejście to nie wyeliminowało potrzeby
zatrudnienia wykwalifikowanej w tym kierunku osoby.

\subsection{WebMO}

Opisana poniżej aplikacja nie jest metodą na generowanie interfejsów aplikacji dla Unicore. Jest za
to dobrym przykładem systemu do obliczeń rozproszonych, którego klient jest osadzony w przeglądarce
WWW.

\emph{WebMO} \cite{webmo} jest ciekawą aplikacją z pogranicza koncepcji przetwarzania gridowego.
Składa się z części serwerowej i klienckiej. Ta druga uruchamiana jest jako aplikacja internetowa.
Cały pakiet pozwala na korzystanie z dobrodziejstw chemii obliczeniowej. Za jego pomocą możemy
wygenerować zadanie do obliczenia w formie modelu trójwymiarowego, korzystając ze strony
internetowej z osadzonym apletem Java do wizualizacji 3D. Zadanie takie może zostać przesłane na
serwer, gdzie zostanie obliczone, a jego wynik przesłany z powrotem do klienta i zwizualizowany
ponownie jako model 3D, wykres lub animacja.

Pakiet \emph{WebMO} jest doskonałym przykładem aplikacji rozproszonej, która posiada bardzo
przyjazny i przede wszystkim efektowny interfejs użytkownika. A wszystko to jest dostępne w
przeglądarce WWW.

Wadami tego projektu jest niestety zamkniętość źródeł programu oraz fakt, że jest on dość mało
funkcjonalny jak na aplikację naukową.

\section{Podsumowanie}

Praca nad interfejsami graficznymi jest mozolna, ponieważ aplikacje naukowe szybko ewoluują nie
tylko dodając, ale także zmieniając udostępnione przez siebie opcje, co modyfikuje pliki wejściowe i
wyjściowe. Aktualny sposób rozwoju interfejsów do aplikacji nie nadąża za tymi zmianami. Szybka
synchronizacja nie jest możliwa, ponieważ ludzie tworzący oprogramowanie naukowe to z reguły osoby
bez wykształcenia informatycznego. Mają oni niewielkie doświadczenie oraz umiejętności w tworzeniu
interfejsów graficznych.
